Home | | Latest | About | Random
# Week 1 Monday
Dear Class,
This week we will discuss **sections 4 and 5** in the online free textbook [https://www.pic.ucla.edu/~mjandr/resources/10A-textbook/](https://www.pic.ucla.edu/~mjandr/resources/10A-textbook/) (remember to **RT(F)B**!). Please allow me to experiment with different ways of lecturing. If anything is unclear or skimmed, please **always read the book** and come to us during **Student Hours**, we want to help you! And work with and learn from each other! Also, don't forget **HW0** is due **this Wednesday at 10pm**!
Section 4 discusses errors and section 5 discusses data types, operations on numbers, const, and casting.
The following still follows the book rather closely, just vary in presentation.
-- B.
## Warm-up.
Using what you have learned from last week and from the reading, try writing a C++ program that prints out the following cartoon cat to the console:
```cmd
/\"/\
( o.o )
= ^ =
```
Too easy? How about this logo? Watch out for some pesky characters!
```cmd
8888888888888888888888888888888888888888888888888888888
8888888P88888888888888888888888888888888888888888888888
88888 "888888" "88888888888888 888888888888888888
8888 9o "8888P 8888888888888 88 888888888888888888
8888888" 98888 d888888888888 8P 8888888888888888888
8888888 8888P 888" 98888 P 8888 '9P"988888888
888888 98888 888 d8b 9888 d88 d8o .88888888
88888b 88888 88 d88 888 d88 8888 888888888
88888b .8888 8P 888b888 988 888P 888888888
88888b "8 "8888P d8b P 988" 8P 888888
888888b. ob db. .d8888. 88 d8 d888888
8888888888888888888888888888888888888888888888888888888
8888888888888888888888888888888888888888888888888888888
```
Yep. This is done by hand, and so can you! Exercise your creative and make some (ASCII) art like this!
## Syntax is important!
**"I watched the cat with the fish on the log."** What does this mean?
![[1-teaching/ucla-2026-fall-pic-10a/---files/i-saw-the-cat-with-the-fish-on-the-log.png]]
## What happens when you press "Play" in your IDE.
Once you have written a C++ program in your IDE and you press the "Play" button, what actually happens?
![[1-teaching/ucla-2026-fall-pic-10a/---files/build-and-run.png]]
- Suppose you have written some C++ code, and saved it as `main.cpp`, say (and possibly some other files `*.h`, `*.hpp`, etc.). These are your "human readable source code".
- When you hit "Play" in your IDE, these files are fed into a **C++ compiler**, which is a software that attempts to **build** an **executable**. Building consists of (1) compiling (translating) your files into machine code, and (2) linking them together, often if there are multiple files.
- If this is successful, we get an executable, saved somewhere on your computer. This executable is a program that contains *machine instructions* that machine can understand. In other words, the compiler translates our instruction in C++ language into machine language (which really is in binary, that looks like `00100100101...`). This is why executables are sometimes called *binaries*.
- Then, your IDE proceeds to **run (execute)** said executable file.
- And if this is successful, this produces some output (like printing to the console) or performs some task that we programmed it to do in the first place. Hopefully this does what we would have hoped!
- Finally, if the task is performed without an error, and the task is completed, then it exits with a exit status code of whatever we've set, customarily 0.
Random historical fun fact about programs in binary. Look up *core rope memory*, which is what stored the programs that helped navigated Apollo 11 to the moon! (See: [Software woven into wire: Core rope and the Apollo Guidance Computer](https://www.righto.com/2019/07/software-woven-into-wire-core-rope-and.html?m=1))
## Errors that can arise.
By looking at the diagram above, we can see at least two places error can occur: During building and during running. We will describe four categories of errors.
1. Build-error.
2. Runtime-error.
3. Undefined behavior.
4. Errors that are none of the above
- Logical error
- Design error, etc
### Build-errors.
**Build-errors** may occur during the compilation stage or the linking stage. These are errors that the compiler would not even compile an executable. Often this is due to **syntax error**, or using "things" that are not "previously defined". Build-errors can also occur when dealing with multiple files when linking. But we are not dealing with multiple files yet, so it'll mostly be compilation errors for now.
Try to find the build-errors in the following examples. Identify which line and explain.
```cpp
int main(){
return "Hi Mom!";
}
```
```cpp
#include
int main(){
cout << "Hi Mom!";
return 0;
}
```
```cpp
#include
int main(){
std:cout << "Hi Mom";
return 0;
}
```
```cpp
#include
using namespace std
int main(){
cout << "Hi Mom";
return 0;
}
```
```cpp
#include
using namespace std;
int main(){
cout >> "Hi Mom";
return 0;
}
```
### Runtime-errors.
If somehow the compiler builds successfully an executable, but during the execution of this executable the program stops unexpectedly due to an error. Then this is a **runtime-error**.
Let us set up an example with the `string` class, something we will discuss more in the very near future:
```cpp
#include
#include
using namespace std;
int main(){
string s("Hello");
cout << s.at(4);
return 0;
}
```
Here there is something called `s` that is a `string`, which is made using the string literal `"Hello"`. This thing `s` has a member function called `at(size_t i)`, which returns the character at position `i`. In this case at position `4`, it'd give the character `o` (as we count starting from `0`).
The following here runs into a runtime-error:
```cpp
#include
#include
using namespace std;
int main(){
string s("Hello");
cout << s.at(10);
return 0;
}
```
This is the same set up as before, except it tries to give the character at position `10`, which `s` does not have, it is out of bounds! Here an error is thrown because the member function `at` for the `string` class performs bounds-checking.
### Undefined behavior.
The C++ Standard lays out the rules and syntax of the language. But there are times where
1. The Standard explicitly states the behavior of a coding scenario is left undefined;
2. The Standard omits certain definition, implicitly leaving the behavior undefined;
3. The Standard lays out certain *preconditions* or *constraints* for a scenario, and violating theses constraints leaves it undefined.
In these cases, it leaves it up to the compiler to handle them, and different compilers may handle it differently! These are called **undefined behaviors (UB)**. These undefined behaviors may lead to
- Build-error.
- Runtime-error.
- The code runs but with dangerously unintended behavior.
- The code executes with different behavior under different levels of optimization during compilation, as the compiler assumes there is no undefined behavior in your code.
Bottomline, undefined behaviors are **bad**, and your code should **not** rely on these behaviors, even if it compiles and executes!
Here's a similar looking example, but different:
```cpp
#include
#include
using namespace std;
int main(){
string s("Hello");
cout << s[10];
return 0;
}
```
Here we instead try to access the character at position `10` using the `operator[ ]` instead. Some compilers will throw an out of bounds error, some will not!
Here is a more striking one
```cpp
#include
using namespace std;
int main(){
const char s[6] = "Hello";
cout << s[10];
return 0;
}
```
Yikes! It may print out garbage sometimes!
If you are interested you can look up how **a lot of security exploits are due to exploiting undefined behaviors...**
### Errors that are none of the above.
Sometimes you make create an error that is none of the above, that the code runs except it is not what you expected. This might due to **logic error** (or **design error**, **intent error**).
For instance, perhaps you tried to calculate the total cost to purchase `N = 10` computers, each at a price of `P = 1500` dollars. You then write
```cpp
#include
using namespace std;
int main(){
int N = 10;
int P = 1500;
cout << N + P;
return 0;
}
```
Here we should have multiplied `N` with `P`, but instead we added them. That's a logic error.
We will deal with math, numbers, and other data types later.
Or, perhaps you meant to display a sentence to greet Spanish speaking users, but you wrote
```cpp
#include
using namespace std;
int main(){
cout << "Bonjour mes amis!";
return 0;
}
```
In any case, these codes all build and execute with no problem, encountering no undefined behavior. But the intent behind these codes are wrong.
Through experience you will be able to spot which kinds of errors you are encountering. **It will be important to be able to recognize what kind and where!** Also, making errors is how we learn! Sometimes you should try to intentionally make errors when you are learning how to code, just to see what exactly is breaking to further your understanding and muscle memory.
---
We ended here Monday. We're a bit behind my imagined-schedule but it'll be ok. Finish reading section 4, and get started on reading section 5 that we will discuss next time.